Secure system and method for enforcement of privacy policy and protection of confidentiality

ABSTRACT

The invention includes various systems, architectures, frameworks and methodologies that can securely enforce a privacy policy. A method is included for securely guaranteeing a privacy policy between two enterprises, comprising: creating a message at a first enterprise, wherein the message includes a request for data concerning a third party and a privacy policy of the first enterprise; signing and certifying the message that the first enterprise has a tamper-proof system with a privacy rules engine and that the privacy policy of the first entity will be enforced by the privacy rules engine of the first enterprise; sending the message to a second enterprise; and running a privacy rules engine at the second enterprise to compare the privacy policy of the first enterprise with a set of privacy rules for the third party.

This divisional application claims priority to U.S. Pat. No. 7,401,352entitled SECURE SYSTEM AND METHOD FOR ENFORCEMENT OF PRIVACY POLICY ANDPROTECTION OF CONFIDENTIALITY, filed on Aug. 30, 2002 and co-pendingU.S. patent application Ser. No. 12/136,544 entitled SECURE SYSTEM ANDMETHOD FOR ENFORCEMENT OF PRIVACY POLICY AND PROTECTION OFCONFIDENTIALITY, filed on Jun. 10, 2008, the contents of which arehereby incorporated by reference in their entirety.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates generally to network-based data privacypolicies, and more particularly to a system and method of implementing asecure privacy policy.

2. Related Art

As the amount of information transmitted over networks by businesses,individuals and other entities continues to grow, the ability toguarantee privacy of information has become an ongoing challenge. Forexample, users that subscribe to a provider's services are oftenrequired to disclose sensitive personal information such as credit cardinformation, medical information, family information, etc. The onlysafeguard available to such users is the privacy policy of the provider.Unfortunately, it is often impractical for an end-user to manually checkthe privacy policies of each provider that they may encounter,particularly in a network environment such as the Internet wherepolicies can change over time and the actual provider of some service(e.g., credit approval) may be transparent to the end-user.

To address this, automated privacy policy matching systems have beenproposed that compare the privacy requirements of a user with theprivacy policy of each provider to ensure that the privacy rights of theuser are maintained. In such systems, data is only released if theprivacy constraints of the user can be met. Thus, an end-user can beconfident that any entity collecting their personal data will not usethe data in manner that is proscribed by the end-user. Such a system isdescribed in U.S. Pat. No. 7,478,157, entitled “System, Method, andBusiness Methods for Enforcing Privacy Preferences on Personal-DataExchanges Across a Network,” which is hereby incorporated by reference.

Unfortunately, the efficacy of such privacy policy matching systems iscompletely dependent on the integrity of the people and organizationsthat provide the services, or otherwise have access to the data. Forinstance, even though a provider may guarantee data will not be used orsold without the consent of the end-user, there is nothing to prevent anemployee of the service provider from stealing personal information.Accordingly, present matching systems may not always provide thenecessary level of security to guarantee privacy.

Additional issues arise in a business-to-business (B2B) orenterprise-to-enterprise (E2E) environment where personal data of an enduser is transmitted between two or more businesses or entities during atransaction in which the end-user is not a direct party. For example,during a credit card purchase, a merchant must transmit sensitiveinformation (e.g., credit card information) to a financial institutionfor approval. In a second example involving automotive telematics, anautomobile may be required to transmit data to a service providerrelating to the location of the vehicle, miles driven, etc. In thesecases, like those mentioned above, the mere fact that the involvedentities have a privacy policy matching system does not guard againstoutright theft and/or tampering. Accordingly, a need exists for aprivacy policy system that includes the necessary security to ensuredata privacy.

SUMMARY OF THE INVENTION

The present invention addresses the above-mention problems, as well asothers, by providing various systems, architectures, frameworks andmethodologies that can enforce a privacy policy in a secure environment.In a first aspect, the invention provides a method for securelyguaranteeing a privacy policy between two enterprises, comprising:creating a message at a first enterprise, wherein the message includes arequest for data concerning a third party and a privacy policy of thefirst enterprise; signing and certifying the message that the firstenterprise has a tamper-proof system with a privacy rules engine andthat the privacy policy of the first entity will be enforced by theprivacy rules engine of the first enterprise; sending the message to asecond enterprise; and running a privacy rules engine at the secondenterprise to compare the privacy policy of the first enterprise with aset of privacy rules for the third party.

In a second aspect, the invention provides an automotive telematicssystem having a privacy protection framework, comprising: a plurality ofsensors for collecting sensor data from the automobile; and a dataprotection manager for managing the sensor data, wherein the dataprotection manager includes: a system for receiving data requests forsensor data from a plurality of applications; a system forauthenticating an application anytime a data request is made from theapplication; a system for storing each data request in a data log; and aprivacy engine that ensures that each application requesting data has aprivacy policy that complies with a privacy policy of the privacyengine.

In a third aspect, the invention provides a method for securelyguaranteeing a privacy policy for credit card transactions, comprising:building a plurality of data processing devices that can recognize eachother using cryptography; programming a privacy policy into each of thedata processing devices; certifying that each of the data processingdevices are equipped with privacy policy enforcement means; distributingthe data processing devices to a merchant and a financial institution;issuing a credit card to an end user from the financial institution,wherein the end user is assigned a privacy policy in the data processingdevice of the financial institution; making a credit card purchase fromthe merchant by the end-user; and requesting data from the financialinstitution's data processing device by the merchant's data processingdevice, wherein the type of data that can be provided to the merchant'sdata processing device regarding the end user is governed by theassigned privacy policy of the end user.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features of this invention will be more readilyunderstood from the following detailed description of the variousaspects of the invention taken in conjunction with the accompanyingdrawings in which:

FIG. 1 depicts an enterprise-to-enterprise framework for implementing asecure privacy policy system.

FIG. 2 depicts a method of implementing a secure privacy policy systemin a credit card transaction environment.

FIG. 3 depicts an overview of an automotive telematics system.

FIG. 4 depicts an architecture for enforcing a privacy policy.

FIG. 5 depicts an architecture for enforcing a privacy policy in anautomotive telematics environment.

The drawings are merely schematic representations, not intended toportray specific parameters of the invention. The drawings are intendedto depict only typical embodiments of the invention, and thereforeshould not be considered as limiting the scope of the invention. In thedrawings, like numbering represents like elements.

DETAILED DESCRIPTION OF THE INVENTION 1. Overview

As noted above, the present invention provides various mechanisms forsecurely guaranteeing a privacy policy between two enterprises. Ingeneral, a privacy policy dictates the type of information or data thatcan be transmitted from one enterprise to another enterprise regarding athird party. The present invention sets forth various secure embodimentsthat ensure compliance with the privacy policy. For the purposes of thisinvention, the term enterprise may comprise, e.g., any type of business,machine, application, device, vehicle, appliance, etc.

2. Generic Enterprise-to-Enterprise Model

Referring first to FIG. 1, a generic enterprise-to-enterprisearchitecture 10 in accordance with the present invention is shown. Eachenterprise (i.e., Enterprise 1 and Enterprise 2) comprises variouscomponents for managing profile data 16 protected by privacy rules 18.Profile data 16 may comprise any type of data (e.g., financial,personal, health, etc.) that a third party might entrust to a respectiveenterprise, subject to a set of privacy rules, i.e., a privacy policy.In the case of an automotive system, the third party may be a driver orowner of a vehicle and the enterprise may be represented by a computingsystem with the vehicle or a computing system location at an applicationor telematics service provider.

In the described embodiment, the components are implemented in softwareand are stored on tamper-proof secure hardware, such as an IBM™ 4758 PCICryptographic Coprocessor (hereinafter “4758”). The components include:(1) a responder 20 that manages requests and responses for profile data16; (2) a privacy-enabled resource manager 22 that intercepts allrequests for profile data 16, and calls (3) a privacy rules matchingengine 24 to verify that the requesting enterprise does not violate theprivacy rules 18 associated with the profile data 16. Note that both theprofile data 16 and the privacy rules 18 are both considered to bepersonal data, and protected by privacy rules 18. Privacy-enabledresource manager 22 maintains and manages the profile data 16 (i.e., itis responsible for updating, creating, and deleting data).

Interaction between each Enterprise 1 and Enterprise 2 is as follows.Enterprise 2 sends Enterprise 1 a message containing a request for dataabout a third party as well as Enterprise 2's privacy policy. Therequested privacy policy may be specific to the third party or be ageneric policy for Enterprise 2, in which case it might not need to besent each time. The request is signed and certified, such thatEnterprise 1 can be assured that Enterprise 2 has a tamper-proof, securesystem, and that the privacy policy of Enterprise 2 will be enforced bythe privacy rules engine in Enterprise 2.

Once Enterprise 1 receives the request, it is processed by the responder20, which sends the request to the privacy-enabled resource manager 22.The privacy-enabled resource manager 22 calls the privacy rules matchingengine 24, which matches the privacy policy and request from Enterprise2 with the rules for the third party at Enterprise 1. If the matchsucceeds, then the privacy-enabled resource manager 22 retrieves therequested profile data, and returns it to the responder 20. Theresponder 20 encrypts and signs the response, which is returned toEnterprise

As noted above, each request for information is signed by the requestingenterprise and certified. Certification assures the enterprise receivingthe request that the requesting enterprise will guarantee theenforcement of privacy policies. The validity of such a certificationcan be readily determined by, for example, consulting a list ofcertified enterprises maintained by a trusted third party agency.Trusted third parties, or trusted intermediaries, are mutually trustedentities that are commonly used to certify or witness transactionsbetween two or more potentially hostile parties in a transaction.Examples include companies such as VERISIGN™, a certificate authorityand trust services provider, or nonprofit organizations such as TRUSTe™,which provide privacy policy disclosure and attestation services.Another example of trusted third parties is the Key Distribution Center(KDC) in the Kerberos authentication protocol, which is an entity thatis trusted with the identification information of all parties on anetwork/system for the purposes of authenticating resource usage. As analternative, a hardware manufacturer could build a series of machinesthat could provide the necessary certification. Such an embodiment isdescribed next with reference to a credit card transaction system.

3. Credit Card Transaction

As noted above, one of the challenges of providing a secure privacypolicy framework involves certifying that an enterprise requesting datawill implement and enforce its published privacy rules. Thus, forinstance, in a credit card transaction environment as shown in FIG. 2, afinancial institution 32 must release financial data 33 to a merchant 34when an end-user 36 makes a credit card purchase 35. Even thoughmerchant 34 may publish a privacy policy, without some security, thereis no guarantee that merchant 34 will abide by the policy.

The present embodiment addresses this by producing a series of“pre-configured” data processing devices (i.e., machines 31) that canrecognize each other using any of a set of well-known cryptographicmechanisms. In this case, manufacturer 30 would build the whole seriesand certify all the machines are equipped to enforce privacy andconfidentiality policies. Each machine would be built for a specificuser, e.g., financial institutions, merchants, end-users, identityservice providers, etc.). An “identity service provider” is a servicethat provides and/or certifies information about a person. It couldprovide, for example, basic authentication or other information about aperson. For example, it may automatically fill in forms or certifyfacts, such as might be needed to complete a transaction, e.g., legalage, credit-worthiness, etc. When the policy is written or at the timethat it is created, only the publicly known rule of the business, e.g.,merchant, financial institutions, merchants, end-users, identity serviceproviders, etc., and the decision of the customer would be permitted torule, and the will of the customer would be respected with no possibleinterference, except possibly by government agencies with properwarrants.

The enforcement part would be accomplished, for instance, by using theteachings of above described patent application “SYSTEM, METHOD, ANDBUSINESS METHODS FOR ENFORCING PRIVACY PREFERENCES ON PERSONAL-DATAEXCHANGES ACROSS A NETWORK, which would provide a secrecy barrier usingcryptography with a 4758 or a similar machine.

To operate credit and charge card transactions, card data from end-user36 would be encrypted and sent to the merchant's 4758, and from there tothe financial institution 32 for validation and all aspects ofexecution. The merchant's 4758 would be securely configured by themanufacturer 30 to only allow access to, for example: (1) limited typesof data or identifiers (set by the privacy policy) of the customer; (2)the financial institution's commitment to the merchant; (3) and theamount money involved. Other enterprises involved in such a transactionwould have similar limitations pre-configured into their own machines31.

The use of private key/public key pairs (i.e., public schemes) as meansto encrypt or digitally sign a file or document using secret encodingkeys or secure hash functions (such as SHA-1, as fully specified in theFederal Information Processing Standard Publication 180-1) are wellknown. A description of these techniques with directions on how to useseveral of their implementations can be found in “Handbook of appliedCryptography”, by Alfred J. Menezes, Paul C. van Oorschot and Scott A.Vanstone, CRC Press, 1997. Another important enabler of secureelectronic communication is to exchange secret keys while exchangingonly messages that can be understood by third parties. Several protocolshave been created to this effect, such as Diffie-Hellman. In the contextof the present invention, this would be used, for instance, to create aseries of machines that can recognize each other. The ability to“recognize” allows for the authentication of machines to each otherbased upon mutually respected cryptographic certification, and hence,their ability to trust each other based on those cryptographicallyauthenticated identities.

The above-described environment would allow the end-user 36 to makesecure credit or debit card payments over the World Wide Web. Namely,when the end-user 36 is dealing with enterprises that utilize the securesystems described above, the end-user 36 could receive somecertification via their browser that the merchant they are dealing withonly has access to the information agreed upon between the end-user 36and the financial institution 32. In this case, the end-user could alsobe provided with a data processing system (e.g., software, such as adownloadable pluggin; or secure hardware) that would provide a secureinterface. Using such a system, merchants and financial institutionwould be allowed to operate at moderate costs while providingcertifiable privacy and security.

4. Automotive Telematics

A further embodiment where privacy policy security is desirable involvesautomotive telematics, where information from automotive vehicles isbeing collected for various purposes. Automotive telematics utilizesinformation-intensive applications that are being enabled for vehicles(automobiles, trucks, buses, etc.) by a combination oftelecommunications and computing technology. The automobile is, ineffect, a computing platform to which mobile commerce services may bedelivered. The services being delivered today on a regular basis andprojected for the near future include navigation information, emergencyroadside assistance, location-based services, delivery of digitalinformation such as e-mail, entertainment, diagnostics and prognostics,and pay-for-use rental and insurance. These applications are enabled bythe collection and use of data which may include information on thelocation of a vehicle as a function of time, emergency situationsincluding accidents and personal health emergencies, diagnostic data onthe many systems within the vehicle, services and entertainment that areselected by the vehicle occupants, the demographics of the driver andpassengers, and the behavior of the vehicle driver. Location informationmay be based upon GPS (Global Positioning Satellite) information andinclude longitude, latitude, altitude, and a time stamp.

In the automotive telematics environment, there is a significantpotential for the misuse of collected data. End users or consumers maysubstitute false data or hack into in-vehicle applications in order toavoid costs associated with provided services. Telematics serviceproviders and application providers may sell consumers' data to thirdparties without the permission of the consumers. Accordingly, thepresent embodiment provides various safeguards to help guarantee thesecurity data subject to one or more privacy policies.

FIG. 3 depicts an overview of a typical automotive telematicsapplication 40. Cars 42 are equipped with a wireless communicationdevice, a variety of sensors, and a car computer that has a display,sufficient memory, storage, and processing to run complex embeddedapplications and middleware. The car computer interfaces to a car busand other car sensors, for example, a Global Positioning System (GPS)sensor, and collects car engine performance data, safety information,and car location.

Car users subscribe to a telematics service provider (TSP) 44 to get avariety of services from application service providers (ASP's) 46, whichmay include Pay-for-Use Insurance, Information, and Car Care andEmergency Assistance. In order to get services from an ASP, a car userneeds to send some or all the information collected by the car computerto the ASP. In the framework of FIG. 3, each car transmits data asnecessary to the TSP 44, which then provides data to different ASPs asneeded. In this case, the TSP acts as a service aggregator and a databroker. Data that is aggregated may be derived from many sensors locatedin one vehicle or from many vehicles. In addition to the datatransmitted by cars, the TSP can store user preferences and usersubscriptions to services. Thus the TSP may subscribe to data, e.g. thedata is transmitted by the car at intervals, or the data transmissionmay be event based, e.g. sent to the TSP when assistance is required.

As shown, different ASP's often need different user data and use it fordifferent purposes. The Pay-for-Use Insurance ASP may need useridentification data, GPS data, miles driven to compute premiums andperform risk analysis. The Information ASP may need user location, anduser preferences to send back information on local attractions. The CarCare and Emergency Assistance ASP may need car engine performance andsafety information on regular basis, and car location in case ofemergency. As is evident, not all ASP's need the same information. Forinstance, data identifying the user is not required for the InformationASP, but is required for the Pay-for-Use Insurance ASP.

Dynamically generated data within an automobile creates unique securitychallenges. The sheer amount of the data generated makes it difficult,if not impossible, to store it within the automobile itself.Accordingly, certain pieces of data must be stored outside of theautomobile (e.g., by a trusted third party on behalf of the individual)thereby emphasizing the importance of the driver's privacy policies.Moreover, unlike static data which has to be collected only once by anyinterested party, dynamic data has to be collected repeatedly by aservice provider to keep it up-to-date. Thus, a continuous transfer ofdynamic data to more than one service provider, governed by differingprivacy policies is often required. Accordingly, a data protectionframework is needed to ensure that each ASP is indeed enforcing itsprivacy policy.

The data protection framework of the present embodiment is built on thefoundation of privacy and security technologies. The privacy technologyenables users and service providers to define an underlying data model,and to define policies authorizing access to data. The securitytechnology provides traditional capabilities such as encryption,authentication, and non-repudiation. Non-repudiation is the property ofa cryptosystem whereby parties are unable to deny actions they perform,e.g., not being able to deny after the fact that you authorized apurchase/transaction. In addition, the security technology providessecure environments for protected execution, which is essential tolimiting data access to specific purposes.

User-defined policies specifying personal data handling preferences, andsolution provider policies attesting to user data handling practicestogether form virtual contracts between users and ASP's. The presentframework enables enforcement of these policies by categorizing sensordata and defining data handling rules according to classifications andpolicies, and by assuring ASP compliance to the rules. Enforcement ofpolicies and compliance assurance extends from the in-vehicle client tothe solution or service provider back-end systems, and can be extendedto third-party interactions within the domain of the framework.

Security and privacy policy enforcement relies on the classification andprotection of data upon its creation, storage, transmission, usage, anddestruction, ensuring integrity of the data for both users and ASP's.Data protection is achieved in part by employing cryptographicalgorithms and protocols, both for confidentiality as well as forintegrity, authentication and authorization. Data classification andprotection also extends to solution or application integrity.Applications must first be authenticated; then executed in compliancewith applicable policies and rules that are validated and auditable; andthe framework will enable the secure configuration and update ofapplications as well as of the framework components themselves.

Referring to FIG. 4, a data protection platform architecture 50 isshown. Architecture 50 can be instantiated in car, in TSP and in ASPsettings by choosing appropriate implementations of the two bottomlayers 52, 54. In a car environment, an RTOS (real-time operatingsystem) such as Neutrino™ by QNX™ may be utilized, whereas the TSP andASP may use server operating systems such as LINUX™. The applicationserver for in-car environments may use an OSGi (Open Services GatewayInitiative) based platform, while remote application servers may useWebSphere™ by the IBM Corporation, for example. The Platform ProtectionManager, which is a part of the operating system, OS, monitors theintegrity of all system software including the Data Protection Manager56 and provides security functions such as verifying signatures onapplications. The Communications layer 58 handles encrypted,authenticated, and monitored network connections. For example, itsupports protocols like SSL (Secure Sockets Layer) or IPSec (IP(Internet Protocol) Security Protocol). The DBMS (database managementservices) layer 59 provides basic storage capabilities for the DataProtection Manager 56. The Data Protection Manager 56 is the key privacytechnology, which regulates application access to data and enforces allother aspects of the privacy policy such as retention constraints.

Communication between data sensors and applications may utilize thearchitectural framework 60 shown in FIG. 5. In this embodiment, avirtual blackboard provides a data processing environment that existsboth locally (i.e., on the automobile) and remotely (e.g., at an ASP).Data Protection Manager 56 provides an interface for informationproducers such as sensors or aggregation applications to publish data onthe blackboard. Information consumers access this data through periodicqueries or through a subscription/notification mechanism. Because theblackboard paradigm is extended across a virtual network, applicationsat the TSP or ASP can submit queries to, or receive notifications from,the in-car blackboard mechanism.

The embodiment of FIG. 5 illustrates how applications are implemented.In this case, a GPS sensor may periodically publish location data itemsin the Data Protection Manager 56 via a GPS adapter 64 and sensorservice 66. An application, such as the Classified Mileage Calculator 62can subscribe to the GPS data and compute (with the help of a road map)the total mileage driven on different types of roads. The results areagain published in the Data Protection Manager 56. A Risk Analysisapplication running on the insurance server remotely can also subscribeto the aggregated and classified mileage data.

Blackboard-based architectures provide a simple paradigm forimplementing sensor-based applications. In addition, because every dataaccess passes through the central Data Protection Manager 56, theblackboard approach provides another key advantage for a privacyprotection framework that requires verifying that data accesses complywith the appropriate privacy policies. To this end, RequestAuthentication 70 first authenticates a requestor, then the request isstored in Log Service 72, and finally the Privacy Engine 74 examines therequest. Only if the request complies with the policy, data is returnedto the requestor by Data Service 76.

The Data Protection Manager 56 provides the core functionality neededfor data protection. As can be seen in FIG. 4, it controls access toprivate data, user policies, configuration data, and an applicationregistry. All applications needing access to private data must be signedand must register with the Data Protection Manager 56. The applicationserver 52 entrusts its configuration data to the Data Protection Manager56 and is by default registered with it. In this sense, applicationserver configuration data is a special type of private data.

The Privacy Enabled Resource Manager (PERM) component 53 handlesadministration of data models, policies, and application registration.In addition, PERM handles requests for private data. A typical requestfor data includes application credentials, privacy policy data, anddescription of data items. The PERM first verifies applicationcredentials. Upon successful verification of credentials, the PERMcompares an application privacy policy with the user's privacy policy todetermine whether to grant access or not. In addition to supportingrequest/response protocol, PERM also supports the subscription model fordata.

Since protection of information—user data, vehicle data, time andlocation information, and even executable software—that is generated orstored in, or transmitted to/from, the in-vehicle client platform is keyto the success of automotive telematics, our security focus of thepresent embodiment seeks to ensure the integrity of such data during itslife cycle. Security is provided from a bottoms-up perspective startingwith the physical client platform itself. The view extends to the secureconfiguration and update firmware/software—the software that is first toexecute and assures the secure instantiation of subsequent softwarecomponents, including the system software (e.g., embedded operatingsystem), middleware, and application support. Each layer of hardware andsoftware provides its own security-related features. This concept ofhaving multiple layers of protection with the goal of preventing asingle point of compromise is called defense-in-depth. Together, thephysical client platform and the various software layers comprise asecure execution environment.

The security features offered by the in-vehicle client platform, as wellas the telematics services and solutions providers' platforms, will inlarge part determine the degree to which data privacy and protectionassurances can be given. While the software components of the end-to-endframework may and should be vetted for security and for compliance to aprivacy protection design, hardware components of the framework maystill be vulnerable to attack or misuse both from within (e.g., users,service providers) as well as from external parties (e.g., hackers,thieves, competitors).

Ideally, physically and logically secure systems are to be used for thein-vehicle clients as well as services and solutions providers'servers—i.e., systems that would resist most physical and logicalattacks (e.g., physical penetration, voltage or temperature attacks,power analysis, monitoring of electromagnetic emissions), and sensingand responding to all others before a system compromise (e.g., byrendering sensitive data inaccessible). Secure coprocessors can providephysically and logically secure subsystems that operate in conjunctionwith a local host system, employing cryptographic acceleration hardware,and providing a secure execution environment for the programs that aresupposed to be run. Such secure coprocessors the IBM 4758 PCICryptographic Coprocessor, a product used extensively in servers forapplications requiring the highest levels of assurance (e.g., bankingand financial applications, electronic commerce systems). Furthermore,the near term future promises similar devices for mobile and clientplatforms, at prices commensurate with such client devices, and offeringperformance capabilities surpassing the current generation ofserver-oriented secure coprocessors. Pervasive low-end securecoprocessors (e.g., smart cards, secure tokens), used for key storageand user authentication, are also currently available and may providesome security assurances in lieu of more comprehensive devices.

Secure coprocessors are also well suited to an emerging industry such asautomotive telematics in that they generally support industry standardinterconnects and communication protocols, allowing for greater ease inporting or integrating with existing telematics platforms. With orwithout physically secure platforms for clients and servers, bothplatforms should allow for secure configuration, update, and execution(booting) of system and application software. Typically, thisfunctionality must exist primarily in the firmware/software that isinitially executed upon power-on (e.g., BIOS or system boot firmware).This power-on software layer is often in read-only memory, it shouldhave minimal complexity and size, and should be able to(cryptographically) authenticate/verify a minimal set of commands anddata that enable the configuration and update of the subsequent softwarelayer (e.g., the system software or operating system layer). Once theplatform system software has been securely configured/updated, thepower-on software layer can authenticate the system software before eachexecution/instantiation, i.e., perform a secure boot.

The operating system, like the power-on software and physical platformbefore, must also provide certain security features, such as accesscontrol, in order to support overall system and data protection. Thereis a great deal of ongoing work in the area of secure operating systems.Elements of the application and application support layer may be highlyintegrated with the operating system. Together, these layers can providesupport for cryptographic programming libraries, secure communicationprotocols, encrypted file systems or databases, firewall and intrusiondetection capabilities, and even virtual machine applicationauthentication, and execution.

Further, because application isolation is important when applicationspotentially come from competing or otherwise mutually hostile parties,the application support layer itself can provide virtualenvironments/machines for the purpose of protecting these applicationsfrom interfering with each other or the operating system.

The application support layer first verifies that the application hasproper credentials. Then it deploys the application in a sandbox toprotect it and other applications. Each sandbox is associated with a setof access privileges defining access to system resources such as filesand sockets. In addition, each sandbox is associated with a name space.By properly structuring execution environment name spaces it is possibleto define which applications and which system resources are available toa given application and therefore control the degree of isolation.Another aspect of isolation deals with application communication. Theapplication support layer prevents direct communication betweendifferent applications and with outside entities. All local and networkcommunication are processed through the Data Protection Manager whichchecks the privacy policies before allowing communication to proceed andgenerates an audit trail for later verification. Requests for data byone application from another application are also similarly checked forprivacy policy compliance. Requests for data and exchanges of data arelogged by the Log Service of the Data Protection Manager. These logs maybe audited later to confirm that privacy policies have been compliedwith.

As alluded to above, the same hardware and software layers, and theirrespective security features, described for the in-vehicle clientplatform are also required for the various telematics service providerservers. End-to-end and life cycle protection of relevant data isassured only when the same level of security is employed across theentire system.

It is understood that the systems, functions, mechanisms, methods, andmodules described herein can be implemented in hardware, software, or acombination of hardware and software. They may be implemented by anytype of computer system or other apparatus adapted for carrying out themethods described herein. A typical combination of hardware and softwarecould be a general-purpose computer system with a computer program that,when loaded and executed, controls the computer system such that itcarries out the methods described herein. Alternatively, a specific usecomputer, containing specialized hardware for carrying out one or moreof the functional tasks of the invention could be utilized. The presentinvention can also be embedded in a computer program product, whichcomprises all the features enabling the implementation of the methodsand functions described herein, and which—when loaded in a computersystem—is able to carry out these methods and functions. Computerprogram, software program, program, program product, or software, in thepresent context mean any expression, in any language, code or notation,of a set of instructions intended to cause a system having aninformation processing capability to perform a particular functioneither directly or after either or both of the following: (a) conversionto another language, code or notation; and/or (b) reproduction in adifferent material form.

The foregoing description of the preferred embodiments of the inventionhave been presented for purposes of illustration and description. Theyare not intended to be exhaustive or to limit the invention to theprecise form disclosed, and obviously many modifications and variationsare possible in light of the above teachings. Such modifications andvariations that are apparent to a person skilled in the art are intendedto be included within the scope of this invention as defined by theaccompanying claims.

1. A method for securely guaranteeing a privacy policy for credit cardtransactions, comprising: building a plurality of data processingdevices that can recognize each other using cryptography; programming aprivacy policy into each of the data processing devices; certifying thateach of the data processing devices are equipped with privacy policyenforcement means; distributing the data processing devices to amerchant and a financial institution; issuing a credit card to an enduser from the financial institution, wherein the end user is assigned aprivacy policy in the data processing device of the financialinstitution; making a credit card purchase from the merchant by theend-user; and requesting data from the financial institution's dataprocessing device by the merchant's data processing device, wherein thetype of data that can be provided to the merchant's data processingdevice regarding the end user is governed by the assigned privacy policyof the end user.
 2. The method of claim 1, wherein the plurality of dataprocessing devices comprise secure coprocessors.
 3. The method of claim1, wherein the plurality of data processing devices can communicate witheach other using private key/public key pairs.